[レポート]Amazon RDS for Aurora Deep Dive #AWSSummit

AWS Summit Tokyo 2015のTA-02: Tech Deep Dive by Amazon:「Amazon RDS for Aurora Deep Dive」のレポートです。

スピーカーはAmazon Data Services Japanの星野豊氏です。

レポート

Auroraは現在Preview中

→頻繁に更新が行われている

→今回の内容は2015/6/2現在の内容のため注意。

→今後も続々と機能追加がされる予定。

Auroraの概要

RDS→データベースを簡単に

データベースを数分で作成可能

S3へのバックアップがあり、リカバリも簡単

Amazon Aurora

re:Invent 2014で発表された、RDSの新しいエンジン

AmazonがRDBを一から作ったらどうなるか？がコンセプト

新しい技術的チャレンジを多く盛り込んでいる

エンタープライズレベルの可用性とOSSレベルのコストを両立

Amazon AuroraはRDSが提供する5番目のDBエンジン

現在Preview中

2015/5/20よりPreviewがプロダクション環境へ移行

Beta環境がクローズ

Beta環境のスナップショットからプロダクション環境で起動可能

GAリリースに向けて頻繁に開発更新中

Amazon AuroraのPricing

r3シリーズのみの提供を予定

今後はc3シリーズもあるかも知れないが、最初はr3限定

ライセンス料金不要

MySQLコンパチなのでロックインも無い

Auroraの特徴

MySQL 5.6と互換性がある

既存のアプリケーションを簡単に移行可能

5.6のマイナーバージョンの発表はしない予定

もし動かない機能があればフィードバックが欲しい

ストレージが自動スケール

プロビジョニング不要

自動的に10GBから64TBまでシームレスに拡張

パフォーマンスインパクトもない

3つのAZに2つずつ、合計6つのデータのコピーを保持

その裏でS3にストリームデータバックアップが取られる

VPCの中で起動、NACLやSecurityGroupにてアクセス制御可能

なぜAmazonがデータベースを作ろうと思ったのか？再考したのか？

現在のDB→モノリシック

複数の機能レイヤーが1つのアプリケーションになっている

スケールアウトする場合にも、全ての機能をセットで増やしていく必要がある

コスト・可用性・柔軟性の面で問題がある

RDBをもう一度考える

Amazonのエンジニアが、このクラウド自体に、一からRDBを設計したらどうなるか？

AWSのサービスが活かせて、スケールアウトが簡単で、セルフヒーリングが出来るようなデータベースが作りたい

ハイエンドDBのような可用性

オープンソースDBのコスト効果

MySQLとの互換性

AWSの各サービスと簡単に連携

そしてフルマネージド

Auroraの仕組み

Service Oriented Architecture

機能レイヤーを疎結合してAPI経由で接続

AWSの既存サービスを管理コンポーネントに採用

バックアップ先にS3を採用し高い可用性を実現

ログとストレージのレイヤーをDBから分離

キャッシュレイヤを分離

キャッシュをデータベースのプロセス外に

→データベースのプロセスに含まれていると、

データベースをリスタートするとキャッシュまで飛んでしまっていた

キャッシュをデータベースから追い出すことで、DBがリスタートしてもキャッシュが消えない

万が一DBプロセスのリスタートが発生しても、キャッシュが残っておりすぐDBを戻すことが出来る

Auroraのストレージ

ストレージも再発明

SSDを利用した、シームレスにスケールするストレージ

プロビジョニング不要なので、実際に使っているデータ分だけが課金される

標準でHighly Availableを実現

3つのAZに6つのデータをコピー

2つが壊れても読み書き可能、3つが壊れても読み込み可能

Log Structured Storageを採用

ディスク書き込み

ホットスポットの影響を取り除く仕組み

負荷が高いディスクがあると除外する

6本全てのディスクへの書き込みをするのではなく

4本のディスクに書き込みが完了すると次の処理を実行

→書き込みが遅くなることはない

ストレージはSSDに10GBずつのブロック内に分散して書き込まれる

リードレプリカもマスタと同じストレージを参照

論理レプリケーションをしていない

S3へのバックアップは増分バックアップ

パフォーマンスの影響が無いようにストリームでバックアップ

再ストライピング、ミラー修復、ホットスポット管理、暗号化など全て自動化

Log Structured Storage

追記型ストレージシステム

ログのようにストレージの末尾にデータを追加するだけ

データの上書きも内部的に全て追記

シーケンシャルに読み出すことが出来る

常に最新のデータが末尾にある

末尾に書き込まれたものをS3に書き込むことでバックアップ取得

ディスク障害の件値と修復

2つのコピーに障害が起こっても、読み書きに影響がない

AZが丸ごと落ちた場合など

3つのコピーに障害が発生しても読み込みは可能

障害検知と修復は自動

レプリケーション

MySQLの場合→binlogをレプリケーションする→レプリカ遅延が起きやすい

Aurora→メタデータの転送だけが行われる

Master/Slave共に同じディスクを見るのでレプリカ遅延は少ない

AuroraではSlaveでもRead Queryが可能

MySQLだと、スレーブが増えるとマスターの負荷がどんどん高くなる

→Auroraだとマスターへの負荷が最小限

最大15台までリードレプリカを作成可能

100ms以内のレプリケーション遅延(高速)

マスターとリードレプリカで同じディスクを見ているので、フェイルオーバーしてもデータロスが発生しない

マスターがしっかり書き込んでいればどのリードレプリカが昇格しても同じデータが見れる

セキュリティ

データの暗号化

SSLを利用したデータ通信の保護

ノードへの直接アクセスは不可能

DBクラスタ

Auroraの概念。マスタ(Writer)とリードレプリカ(Reader)をひとまとめにしたもの。

マスタを指す単一のエンドポイントが提供される。

DB Parameter Groupとは別にDB Cluster Parameter Groupがある。

Auroraが共通で持っていなくてはならない設定を定義、全ノードに適用。

新しいメトリクス画面

selectやcommitのスループット、レイテンシが見られる

全画面ビューが追加されている

最新値とグラフ値が表示

フェイルオーバーとリプレース

リードレプリカが存在する場合→1分程度でフェイルオーバー可能

MySQLよりも高速

リードレプリカが無い場合は10分ほど

Previewで1分程度だが、現在改善中。GAリリース時にはもっと早くなるかも。

優先的にフェイルオーバーさせるノードを1つ指定出来る。

通常はスレーブの一つ。MultiAZに指定することでAZ障害に対応出来る。

障害が発生しAuroraが万が一上がってこなかった場合、どのAZで起動するかを指定可能

クラスタエンドポイント

通常のエンドポイントとは別に、必ずマスタを指す単一のエンドポイント。

通常のエンドポイントで個別にアクセスすることも可能。

クラスタエンドポイントはその時アクティブなAurora WriteのCNAME。

高速なデータ修復

MySQL→シングルスレッドなため適用完了まで時間がかかる

Aurora→並列、分散、非同期で行われる。リカバリにかかる時間が軽減される。

Streaming Snapshot

S3に継続的に増分バックアップを取得

Backup retention periodでバックアップを残す期間を指定可能

PITRから5分前からBackup retention periodまでの任意の位置で、秒単位で、リカバリ可能

SQLによるフェイルオーバーのテスト

alter system crash(データベースノードのクラッシュをエミュレート)

alter system simulate(システムをシミュレート)

Auroraのパフォーマンスを引き出すために

クエリ並列度が高く、データサイズが大きいケースで効果を発揮

ロック機構やクエリキャッシュに手を入れて性能向上を図っている

write heavyでパフォーマンスが出ない場合にはoffにしてみると良い

CPUを効率的に使うため、MySQLと比較すると高くなるが、スループット性能が落ちにくくなっている

CPUが高くなってもスループットと一緒に確認すると良い

パフォーマンステスト

同一ノードから、複数のインスタンスから実施すると、解りやすい

性能が5倍になるケースとは？

sysbenchを4インスタンスからr3.8xlargeのAuroraインスタンスに実行した場合の結果

TPC−Cの場合は2.5倍の結果

MySQLからワンクリックでAuroraにマイグレート可能

一部パラメータ値にないものがあるので注意

MyISAM形式のテーブルの有無で必要なディスク量が変わる

MySQL 5.6からAuroraへレプリケーションを行うことが可能(逆は現時点では出来ない)

EC2上のMySQLやオンプレミスのMySQLからAuroraに簡単に移行出来る

MySQLからAuroraに移行するメリット

クエリパフォーマンスの高さ、ディスク効率、複数の小さなDBの統合など

まとめ

クラウド時代にAmazonが再設計したRDBMS

高いクエリ実行並列度、データサイズが大きい環境で性能を発揮

高可用性、高速フェイルオーバー、PITRを実現するための多くのチャレンジをしている

移行時にはクエリやフェイルオーバーの性能などの検証をしっかりやってほしい プレビューを利用してフィードバックを！

さいごに

Amazon Auroraの仕組みとポイントについて知ることが出来ました。もっとPreviewを使い込みたいと思います。